【レポート】クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン #AWSSummit

こんにちは、佐伯です。

AWS Summit Tokyo 2019 Day3に行われたセッション「クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン」のレポートを書きましたのでご覧頂ければと思います。

セッション概要

オンプレミスのシステムを単純にクラウドへ移行するだけではクラウドの様々なメリットを享受することはできません。このセッションではクラウドネイティブなモダンアプリケーションの開発について、AWSの各種サービスをアプリケーションブロックとして利用するアプリケーション構成やAWSの各種サービスを利用したCI/CDの実現についてアーキテクトやデベロッパーの観点で解説します。

セッションレポート

Agenda

• なぜモダンアプリケーションなのか
• モダンアプリケーション開発とは
• モダンアプリケーションの実装パターン
• AWSにおける継続的インテグレーション/デリバリーの実現

なぜモダンアプリケーションなのか

急速なイノベーションはもはや必須

• 利益を伸ばす
  • 今ある人材を活用
• 新たな機会を探索
  • 新しいアイデアを育てる
• 新たなマーケット
• 新たな顧客価値
• 新たなデジタル製品とサービス

実験→傾聴→反復がイノベーションを加速する

AWSのイノベーションのペース

2017年は1430の新たな機能、サービスをリリース

• 数千のチーム
• マイクロサービスアーキテクチャ
• 継続的デリバリー
• 複数の環境
• 様々なタイプのデプロイ
• 年間数百万回のデプロイ

モダンアプリケーション開発とは

AWSアプリケーションのモダン化のパターン

全部マイクロサービス化やサーバーレス化する必要はない、ひとつずつ調査し優先順位付けをしモダン化のパスを決定することが大事。

• Re-host(list-and-shift)
  • ほとんど変更する必要のない社内システムなど
  • オンプレ -> EC2
• Re-platform(lift-tinker-shift)
  • 並列処理が可能なバッチアプリケーション
  • VM -> コンテナ
• Re-architecture
  • 機能追加要求が多い、大規模アプリケーション
  • モノリス -> マイクロサービス
• Re-invent(CloudNatibve)
  • 迅速なリリースとアップデートを繰り返す新規アプリケーション
  • 最初からサーバーレス化やマイクロサービス化を検討

モダンアプリケーションの能力

• Secure
• Resilient
• Elastic
• Modular
• Automated
• Interoperable

モダンアプリケーション開発のベストプラクティス

• アプリケーションのライフライクル全体に渡ってコンプライアンスとセキュリティを構築
• アプリケーションの構造をマイクロサービスに集まりにする
• 可能な限りサーバーレスの技術で構築する
• アプリケーションのモデリングとインフラにコードを利用する(IaC)
• CI/CDを利用して高品質な昨日を迅速にリイリースする
• モニタリングによってアプリケーションの振る舞いの洞察を得る

アプリケーションのライフライクル全体に渡ってコンプライアンスとセキュリティを構築

• ライフライクルをセキュアにすることでイノベーションの速度を落とすことなく脅威に対応
• 強力なアクセス制御で認証されていないアクセスを防ぐ
• 柔軟なポリシーを使用してロールベースのアクセス制御を実装する
• アプリケーションの振る舞いを評価し、コンプライアンス要件に従っていることを確認する
• 各ステップを検証する
• イノベーションの速度を下げすにセキュリティを担保
• 自動化された、継続的なセキュリティ評価が必要

AWSをセキュリティオートメーションツールボックス

• ID管理
• 発見適当性
• インフラストラクチャ保護
• データ保護
• インシデントレスポンス

アプリケーションの構造をマイクロサービスに集まりにする

• 変更の影響は小さくなると、リリースの速度が向上可能になる
• モノリス(すべてを実行) -> Microservices(ひとつのことを実行)
• APIと疎結合なコミュニケーションが自動化を可能にして信頼性を向上
• イベント駆動にすることで非同期化、一方のサービスが停止してたとしてもキューイングで継続することができる。
• ワークフローで複数のサービスを連携することで、敏捷性、生産性、および柔軟性が向上
• データと処理の状態をトラッキング、冗長なコードを削除
• AWS StepFunctionsのようなワークフローサービス

可能な限りサーバーレスの技術で構築する

自動化と抽象化によって課題から開放

• インフラのプロビジョニングや管理が不要
• 利用単位ごとにオートスケール
• 価値に対して支払う課金モデル
• 高い可用性と耐久性

サーバーレスアーキテクチャは最小の努力で最大のアジリティを提供

• ユーザーはAPIの設計とビジネスロジックにフォーカスできる
• コンピュートの選択はトランスフォーメーションの革新
• サーバーレスファンクション(AWS Lambda)
  • イベント駆動な処理がマッチしている
• サーバーレスコンテナ(AWS Fargate)
  • ロングランニングやバッチ処理に向いている

アプリケーションのモデリングとインフラにコードを利用する

• すべてをソフトウェアとして扱うことでインフラのデプロイスピードとアジリティを向上
• アプリケーションのコードの記述、インフラテンプレートの作成
• 設計→スタックの作成→繰り返し

AWS Cloud Develoipment Kit (CDK)

CloudFormationはYAML/JSONで記述するが、AWS CDKはJavaScript, Java, TypescriptやC#などプログラミング言語で記述しCFnテンプレートを生成。

CI/CDを利用して高品質な機能を迅速にリリースする

CI/CDを自動化しているチームはコードをより早く、自信を持ってコードを書いている。

• 頻繁なデプロイが 33倍 増加
• リードタイムが 440倍 減少
• ミスが 60倍 減少
• 予期しない作業を 21% 削減
• 新しい作業にあてる時間を 44% 増加

AWS Developer Tools for CI/CD

• AWS Codepipeline
• AWS CodeCommit
• AWS Codebuild
• AWS CodeDeploy
• AWS X-Ray

モニタリングによってアプリケーションの振る舞いの洞察を得る

より早く問題を識別すると、より早く解決できる

• メトリクス、ログとトレース
• モニタリング、デバッグ、アラート
• リソース、アプリケーションの可視化
• リアルタイムインサイト

分散されたアプリケーションをどの様に可視化すべきか

モノリシックアーキテクチャはサーバーのモニタリングしてればよかったが、マイクロサービスアーキテクチャは分散しているため情報の収集と可視化が必要となる。

• CloudWatch
  • アプリケーションのモニタリング
  • パフォーマンス変化に応答
  • リソース使用率を最適化
  • オペレーショナルヘルスを一元管理
• AWS X-Ray
  • リクエスト動作の確認
  • 性能のボトルネックを特定
  • 根本原因をトラブルシュート

モダンアプリケーションの実装パターン

APIゲートウェイパターン

APIゲートウェイパターンはバックエンドのAPI呼び出しが多いサービスや、デバイスごとにコンテンツを変えたりするサービスに向いている。

• AWSサービス: AWS API Gateway
  • スロットリング機能
  • キャッシュ機能
  • 認証認可機能
  • AWS APIへのプロキシサービス

サービスディスカバリ/サービスレジストリパターン

マイクロサービス化するとお互いがお互いのサービスの場所を見つける必要がある。起動時にサービスレジストリに自身の情報を登録、呼び出し側はサービスディスカバリを呼び出してアクセス先を見つける。

• AWSサービス: AWS Cloud Map
  • DNS名前解決
  • ARNによる解決

サーキットブレーカーパターン

サービス間連携があるとき呼び出し先のサービスに障害が発生した場合、呼び出し元が再試行を繰り返してしまう。サーキットブレーカーは呼び出しサービス障害時は安全に機能低下しつつ、復旧した場合はリクエストを受け付ける。

• 定期的に呼び出し先のAPIを監視
• サービスが落ちた場合は即座エラー応答
• 復旧したら使えるようにしてくれる

サイドカー方式でサーキットブレーカーパターンを実装するパターンが多い。

• Amazon ECS: Linkerd を作る
• Amazon EKS: Istio + Envoyを使う

コマンドクエリ責務分離パターン(CQRS)

コマンドクエリ責務分離はデータの読み込みと書き込みは違うものだという前提に基づく考えたもの。更新と参照でデータソースを分離、それぞれスケールできるように設計。 注意事項: 書き込み後に読み込み用データソースに反映するので結果整合性を許容できる場合に採用できる

• DynamoDB -> DynamoDB Stream

イベントソーシングパターン

• データの更新をイベントとして共有する
• イベントリストにストア、プロセスを再生することでデータソースを更新
• CQRSパターンの組み合わせられる

• Amazon Kinesis -> AWS Lambda

コレオグラフィーパターン

マイクロサービスにおいて各サービスが自立して動作するのがコレオグラフィ。対比としてひとつのサービスが関連する個々のサービスを呼び出すオーケストレーションと言う。

• Amazon SNS -> Amazon SQS -> AWS Lambda

集約ログパターン

マイクロサービスそれぞれにまたがった情報をどうやってまとめるか。

• Amazon CloudWatch Logs
• AWS X-Ray

Polyglotパーシステンスパターン

• 異なるデータ処理のニーズに対しては異なるデータストレージテクノロジーを利用すると言うコンセプト。
• システム全体で共通のデータソースを選択した場合、要件によってはパフォーマンスへの影響や実装の難易度があがる。
• マイクロサービスごとで要件に最適なデータソースを選択することでパフォーマンスやスケーラビリティが向上するなどのメリットが生まれる

AWSにおける継続的インテグレーションと継続的デリバリー

継続的デリバリーの基本

• バージョン管理されたソース
• 自動化されたソース
• 自動化されたデプロイメント
• 単体テスト、結合テスト
• 継続的デリバリ
• オペレーションダッシュボード

シングルページアプリケーションのデプロイ

Amplify Consoleでソースの変更を検知してビルドとデプロイを実施。

• AWS CodeCommit -> Amplify Console
  • Amplify Console -> Amazon S3 -> Amazon CloudFront (フロントエンド)
  • Amplify Console -> AWS AppSync -> Amazon DynamoDB (バックエンド)

認証が必要であればCognitoも連携できる

コンテナへのデプロイ

AWS CodePipelineでソースの変更を検知してパイプラインを開始。

• AWS CodeCommit -> AWS CodePipeline -> Amazon S3 -> AWS CodeBuild -> Amazon ECR -> Amazon ECS

ECSへのBlue/Greenデプロイ

同様にAWS CodePipelineでソースの変更を検知してパイプラインを開始。CodeDeployでBlue/Greenデプロイ。

• CodeCommit -> CodePipeline -> S3 -> CodeBuild -> ECR -> AWS CodeDeploy -> Amazon ECS

AWS Lambdaへのカナリアデプロイ

• トラフィックコントロールが可能
• 10分間10%のトラフィックを新しいバージョンのAWS Lambdaへルーティングするなどが可能

• AWS CodeCommit -> AWS CodePipeline -> S3 -> AWS CodeBuild -> Amazon S3 -> AWS CodeDeploy -> AWS Lambda

SAMテンプレートをベースにパッケージ化してデプロイする必要があり、CodeStarにサンプルテンプレートが一式入ってるので試してみるには簡単。

なぜAWSでモダンアプリケーション開発を行うのか?

• AWSはイノベータに対してイノベーションや失敗に対する恐れから開放
• ビジネスに価値がある部分に集中できる

まとめ

• AWSがイノベーショや失敗を恐れずに行えるプラットフォームを提供している
• AWSを活用して価値ある作業にフォーカス

感想

クラウドサービスならではのメリットを活かして、まずは失敗を恐れずに試してやってみるってところが一番大事かと思います。なお、アーキテクチャの部分については図がなく分かりづらいと思いますが、後日資料もアップロードされるとのことなので、そちらをお待ち下さい。